Subject: More HPR questions

From: [email-masked] (Matthew Finlayson)
Date: Thu, 19 May 94 15:35:04 BST

Marcia,

Thanks to Ray and Lap for the very full answers to the questions in my emails
of 4/13/94, 4/18/94 and 4/20/94.

A few more queries about the HPR specification.

Bind Request
============

The specification refers to the NCE for the remote end being carried within
the BIND in the APPN-HPR boundary condition flow (figure 10-3). Unfortunately
the Formats section for the BIND (A.2.8) doesn't mention where the NCE ought
to be stored.

Path Switch Controllers
=======================

The specification is slightly unclear regarding the definition of path switch
controllers. Is it valid for an implementation to allow this definition on
a per port (or even per link) basis?

An example where this might be desirable would be a node with both wireless
and "wired" links. The specification seems to allow this possibility (since
the controller status is communicated on the Route Information) but there
seems to be a danger this would impact the path switch FSM (if the local node
changed from being passive to active during a path switch).

Another problem is in the pseudo code in section 9.6.10 which contains the
logic for generating a new route. The code contains the line:

>     If the partner node is mobile then

without defining what is meant by mobile. Should it be replaced by

>     If the partner node is a path switch controller then

or is there another meaning?

Configurable Parameters for SNA-Defined COS
===========================================

The specification suggests that an implementation might like to make the
following HPR parameters configurable on a per COS basis.

-   path switch timer
-   retry limit
-   liveness timer

The specification should define default settings for the SNA-defined Classes
of Services (#CONNECT, #BATCH, etc) - the defaults will probably not suffice
for such a motley collection of COS's.

Status
======

Reading the discussion of the SHORT_REQ timer in the RTP specification
(page 11-12), I am not sure what the correct behaviour should be if
Partner-A decides that he must send (SR, RASAP) while (SR) is already
outstanding. This would occur, for example, if buffers became depleted
immediately after an ARB request had been sent.

Simply sending the (SR, RASAP) message would mean that the SHORT_REQ timer
would be stopped after the reply to the (SR) had been received. As far as
I can see, the best behaviour in this situation would be to initiate a
state-exchange. The incremented SYNC would mean the reply to the (SR) is
ignored.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================